Trigger router and test system including the trigger router

ABSTRACT

A test system  100  that can accept a plurality of plug-in electronic cards in Xi Slots  126  or PXI slots  134  is described. The test or source measure switching system  100  includes a sequencer or sequence engine  130  which is fully capable of executing opcode instructions having potentially indefinite completion times and monitoring multiple asynchronous inputs simultaneously without interrupts. The sequencer  130  is sequential and deterministic to approximately 10 microsecond resolution. The sequencer  130  includes a trigger router which can be a fully configurable trigger input and trigger output routing matrix. Every trigger input can be configured via several detection modes such as active high, active low, level high and level low. Also, trigger outputs can be configured to be triggered on single, multiple or auto triggers if set.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 61/094,969, filed Sep. 7, 2008, which is incorporatedherein by reference in its entirety.

FIELD OF THE INVENTION

This invention relates to electronic systems and more particularly totrigger router and a test system with trigger router.

BACKGROUND

Unlike single function instruments where the firmware is largely staticafter development, since hardware functionality is predefined and fixed,a multi-purpose test system such as a source measure switching systemwith plug-in cards that can be removed and inserted in the field doesnot have this luxury. As new plug-in cards such as switching, signalsource, and instrumentation plug-in cards for the platform aredeveloped, inevitably the main firmware of the test system, which canalso be referred to as a source measure switching system, will sufferfrom a lack of awareness and support features for the new plug-in cardsthat precludes its use without modification.

From a solution standpoint, several options address the issue mentionedabove. The simplest option is to mandate firmware upgrades each time anew plug-in card development occurs. While this is the simplest option,it is also the most costly for both the manufacturer and the customerand limits the appeal of the instrument, given the fairly constant needfor upgrades to the firmware.

The second option takes classes of general plug-in card descriptors todescribe different cards in a reasonably generic manner. Each plug-incard carries a descriptor that the source measure switching system canthen read to determine specific properties of the plug-in card. Althoughthis solution offers significantly better adaptability than the first,when a new plug-in card can not fit into one of the existing descriptorclasses, a mainframe firmware update would be required in order todescribe the functionality of the new class of card. This solution alsosuffers from the problem that it requires a certain degree of rigidityand conformity, even within a descriptor class, to make the solutionviable. This fact effectively limits the ability to create inexpensivehybrid cards that can meet the specific needs of semi-custom,customer-driven applications as an illustrative example.

Test system environments typically require the ability to switch signalsfrom one instrument or instrument to another, be able to measuresignals, or detect stimulus actions in a high speed and deterministicmanner. Given the space premium found in today's testing environments,test applications require test systems that can provide the ability todetect and generate trigger signals for the test system while occupyingthe least amount of space and provide for maximum flexibility.

BRIEF DESCRIPTION OF THE DRAWINGS

The features of the present invention, which are believed to be novel,are set forth with particularity in the appended claims. The inventionmay best be understood by reference to the following description, takenin conjunction with the accompanying drawings, in the several figures ofwhich like reference numerals identify like elements, and in which:

FIG. 1 shows a test system in accordance with an embodiment of theinvention.

FIG. 2 shows a high level hardware/software model of the test system inaccordance with an embodiment of the invention.

FIG. 3 shows a block diagram of card physical memory access registers inmapped mode.

FIG. 4 shows a stage 1 initialization state of the test system inaccordance with an embodiment of the invention.

FIG. 5 shows a stage 2 initialization state of the test system inaccordance with an embodiment of the invention.

FIG. 6 shows a stage 3 initialization state of the test system inaccordance with an embodiment of the invention.

FIG. 7 shows a stage 4 initialization state of the test system inaccordance with an embodiment of the invention.

FIG. 8 shows a trigger input flow diagram in accordance with anembodiment of the invention.

FIG. 9 shows a trigger output flow diagram in accordance with anembodiment of the invention.

FIG. 10 shows a diagram for multiple independent trigger configurationsin accordance with an embodiment of the invention.

FIG. 11 shows a diagram of an auto trigger in accordance with anembodiment of the invention.

FIG. 12 shows a detailed block diagram of the test system in accordancewith an embodiment of the invention.

FIG. 13 shows a backplane board block diagram of the test system inaccordance with an embodiment of the invention.

FIG. 14 shows a diagram of a trigger circuitry in accordance with anembodiment of the invention.

FIG. 15 shows a trigger router matrix in accordance with an embodimentof the invention.

DETAILED DESCRIPTION

While the specification concludes with claims defining the features ofthe invention that are regarded as novel, it is believed that theinvention will be better understood from a consideration of thefollowing description in conjunction with the drawing figures.

The present invention provides for a test system with trigger routerthat has the ability to route and configure trigger signals between acontroller, intermodules and from external sources, coupled with the useof a deterministic sequencer that provides deterministic timing whenoperating in conjunction with a central processing unit (CPU) as shownin FIG. 1.

Non-Real-Time Operating Systems (“Non-RTOS”) such as Linux or Windowsallow the use of standardized development tools and environments withthe disadvantage of their non-deterministic timing that can be adrawback in test system environments where tight system timing andmeasurement throughput are important. Alternatively, real-time versionsof Linux or Windows are available, but they incur increased developmentcomplexity and other tradeoffs.

Referring now to FIG. 1, there is shown a block diagram highlighting atest or source measure switching system 100 in accordance with oneembodiment of the invention. Test system 100 includes a controller suchas a network processor 102. In one embodiment, the controller comprisesan Intel IXP-465 X-scale network processor running a Linux operatingsystem. Other types of high performance controllers as well as otheroperating systems known in the art can be used for controller 100. Aboot Read-Only Memory (ROM) 104 of 64 MB of flash memory loads theoperating system from the ROM 106 which holds the Linux OS image. A 64MB DDR Random Access Memory (RAM) memory 108 holds the OS RAM and alsoholds measurement samples.

The source measure switching system 100 also includes in one embodimenta 10/100 Base T Ethernet port 110 which can be used for systemcommunications as well as downloading new operating system versions andLXI web pages. A USB 1.1 device port 112 allows for an alternativecommand port to the Ethernet port 110. An IEEE-488 standard interface orGPIB bus 114 provides a further alternative command port. A RS-232interface 116 is used for transferring debug messages (Linux consoleoutput). A USB 2.0 Host port 118 allows for connection to an externalUSB storage device to store/recall scan lists and sequences.

An external Trigger In (TRIG IN) input 120 is routed to a sequenceengine 130 so that a trigger signal can be routed through a systemtrigger matrix to other slots, the sequence engine, etc. in the sourcemeasure switching system 100. An external Trigger Out (TRIG OUT) output122 is routed through the trigger router located within the sequenceengine 130 in order to provide a variety of trigger options as will bediscussed further below. A Reference In/Out (REF IN/OUT) clock routerinterface 124 allows a reference clock input to be routed among theslots, or allows a clock generated from a plug-in module to be routed tothe output. The REF IN/OUT 124 can be programmed as an input or anoutput. A bus referred herein as the X Bus 128 allows for one or more Xislot card slots 126 which can accept switching cards or instrumentplug-in modules. The X bus in one embodiment comprises a 66 MHzinstrument bus to communicate with the Xi cards; the X bus includes dataverification and auto-retry. The X bus will be discussed further below.The Xi card slots 126 are also coupled to an analog bus 136. A PXI bus132 is used as an interface between one or more PXI instrument cardslots 134 that can interface/control PXI bus compatible plug-in cards.

In addition to the above, the test system 100 employs a high-speedsequence engine also referred to as a real-time sequencer/scanner 130capable of making deterministic instrument control operations inmicrosecond intervals. Contrast this with a microprocessor running thebest RTOS available and the performance is at best deterministic tosub-milliseconds, or a Non-RTOS operating system such as Windows orLinux with a non-deterministic multi-millisecond response. In oneembodiment the sequencer or sequence engine 130 is implemented via afield programmable gate array (FPGA).

Unlike a microprocessor which typically lacks time determinism (becauseof interrupts and processing delays), the sequencer 130 used in thesource measure switching system 130 is entirely sequential anddeterministic to approximately ten-microsecond resolution. It also isfully capable of executing opcode instructions having potentiallyindefinite completion times and monitoring multiple asynchronous inputssimultaneously without using interrupts—a behavior typically notpermissible in ordinary microprocessors. As shown in FIG. 1, sequencer130 has its own memory 140 for sequence information and data storage.Another memory 138 is also provided for use by the trigger router andother additional functions within the sequencer 130.

In an alternative embodiment, the 130 sequencer can comprise two or moresequencers. For example if two sequencers are present, one is used forimmediate command execution and another can be used for deferred use insequence/scan mode. The two sequencers can be connected to an internalbus arbitrator to prevent contention and also tied to logic necessaryfor communication over an “X Bus” 128 (described below) interface to oneor more installed cards. Additional sequencers beyond two can beutilized for improved system performance, with increased paralleloperation and sequence branching. In order to optimize the platformto/for analog, digital, and switching plug in cards, it was necessary tocreate a new system interface bus which would be optimized for digitalcontrol, configurable triggering and interrupts, high speed, faulttolerant, and also include low noise, high-voltage, high-current, andhigh-bandwidth analog buses. This was accomplished with a new bus designreferred to herein as “X-Bus” which includes high-speed low-noisedigital communications and both differential and single ended analogbuses. The bus structure also includes customizable trigger routingbetween modules. In addition to the custom bus for specializedinstrumentation, the system also includes a standard PXI bus to allowfor the inclusion of standard PXI cards.

The control of the plug in card instrumentation requires the applicationof synchronized and deterministic time-specific commands. This isaccomplished in the instrument through sequencer commands and dedicatedstate machines to control bus communications. The sequencer commands arefirst defined as high level functional operations which can then bebroken down into lower-level sequential operations which can then bestored and executed in a sequencer to control the modules. Rather thancreating a new scripting language for the high-level functionaloperations, our language will be based upon existing industry standardSCPI commands.

In order to reduce CPU and FPGA sequencer external event detectionlatencies, an autonomous trigger router system is introduced. Thetrigger router is a fully configurable trigger input and trigger outputrouting matrix. In one embodiment, the trigger router allows for 16trigger inputs, although a different number of inputs can be designedfor depending on the particular design at hand. Twelve inputs are fromtwelve slots. Two inputs are from two Scan Sequencers, and two are fromtwo external trigger inputs located on the rear panel of test system100. The trigger router can also allow for direct connection betweenmodules in order to achieve minimum latency.

In one embodiment, every trigger input can be configured via 4 detectionmodes: active high, active low, level high, and level low. Every triggerinput can be routed to every trigger output. Every trigger output can beconfigured for input to output delay, output edge active high or activelow, output level high or level low, trigger pulse width, trigger repeatcycles (auto or input triggered), and trigger scan interval timer. Thetrigger scan interval can be configured for up to 1276 hours. Anytrigger output can also be configured to be triggered on single trigger,multiple triggers, or auto trigger if set.

Analog Bus

Test system 100 provides an analog bus 136 including 4 pairs of two-wireanalog bus and 8 single-ended analog bus lines. The analog bus 136allows for multiple DMMs to run on separate analog buses. The analog buslines are designated ABUS1 through ABUS4 for the two-wire buses, andSABUS1 through SABUS8 for the single-ended buses. Each analog bus lineis relay-configurable. Normally (at power-up), the slots on the lefthalf of the mainframe (5 Xi slots for one version) are separated fromthe slots on the right half of the mainframe (4 Xi slots for anotherversion). Each bus can span the halves of the mainframe by closing arelay. There are twelve relay channels that are accessible to the userto connect the analog bus lines.

These channels are controlled by selecting module “0”, which refers tothe mainframe instead of a plug-in module. The channel numbersassociated with these are:

Channel Connects 1 ABUS1 on slots 1-5 to ABUS1 on slots 6-9 2 ABUS2 onslots 1-5 to ABUS2 on slots 6-9 3 ABUS3 on slots 1-5 to ABUS3 on slots6-9 4 ABUS4 on slots 1-5 to ABUS4 on slots 6-9 11 SABUS1 on slots 1-5 toSABUS1 on slots 6-9 12 SABUS2 on slots 1-5 to SABUS2 on slots 6-9 13SABUS3 on slots 1-5 to SABUS3 on slots 6-9 14 SABUS4 on slots 1-5 toSABUS4 on slots 6-9 15 SABUS5 on slots 1-5 to SABUS5 on slots 6-9 16SABUS6 on slots 1-5 to SABUS6 on slots 6-9 17 SABUS7 on slots 1-5 toSABUS7 on slots 6-9 18 SABUS8 on slots 1-5 to SABUS8 on slots 6-9

So, for example, the command CLOSE (@0(1:4)) connects all of thetwo-wire analog bus lines ABUS1 to ABUS4 on slots 1 through 5 to theanalog bus lines ABUS1 to ABUS4 on slots 6 through 9. Similarly OPEN(@0(18)) disconnects analog bus line SABUS8 on slots 1 through 5 fromthe analog bus line SABUS8 on slots 6 through 9. The analog bus does notprovide access to the PXI plug-in modules. Connection to the PXI plug-inmodules is accomplished with external cabling. For the plug-in moduleswhich do support connecting to the analog bus, channels 9001 through9004 shall be used in conjunction with the “[ROUTe:]CLOSe” command toconnect to the selected two-wire analog bus lines. Similarly, channels9011 through 9018 are reserved for connecting the switch card to thesingle-ended analog bus lines. In order for these channel designationsto remain consistent throughout the system, no relay module channel canassign a channel number greater than 8999.

DMM Support

Test system 100 can support up to 4 plug-in PXI DMM in one embodiment.Support levels can be adjusted depending on design requirements. In oneembodiment, the DMM model that has been selected for the platform is theSignametrics SMX2064 DMM. This DMM provides up to 7½ digit accuracy.

The following measurement types can be supported in one embodiment oftest system 100:

DC Voltage;

AC Voltage;

2-Wire Resistance;

4-Wire Resistance;

6-Wire Resistance;

DC Current;

AC Current;

Capacitance;

Inductance;

Diode Characterization;

Period;

Frequency;

Duty Cycle

Count (Totalize);

Time Interval (pulse width); and

Temperature.

The following stimulus types shall be supported in one embodiment oftest system 100 (or designs can includes other stimulus types):

DC Voltage;

AC Voltage; and

Pulse Generator.

Other embodiments of the invention would allow for use of other PXIcompatible instruments.

In FIG. 2, there is shown a high-level hardware/software model of sourcemeasure switching system 100. FIG. 2 shows all the major hardwarecomponents in the system responsible for remote communication to theoutside world 110, 112, 114, an Apache web-server 202 to facilitate LXIsupport, the sequencer engine 130, which is the also the communicationgateway to all cards 204 present in the system, the single firmwarecomponent for the main or core process in the system, and any firmwarecomponents sourced by cards present in the system. With this said, theexact features of the proposed software architecture can be broken downfurther along areas of major functionality.

System Startup and Initialization

Given that the source measure switching system 100 uses a Linux OS inone embodiment, knowing exactly how the system reaches the statedescribed in FIG. 2 proves useful to understanding other architecturalcomponents in the system. One of the capabilities of the sequencer 130and X Bus 128 communication support is an optional feature that allowseach card's physical memory space to be accessed in block memory mappedtransfers to/from the main CPU memory space. The physical card memoryspace is not directly accessible from nor is it mapped into themicroprocessor's memory space since it is substantially larger than themain CPU supports and is further isolated through the X Bus interface128. The importance of this feature from a system startup standpointwill become apparent shortly.

Prior to describing how startup activities in the source measureswitching system 100 use this feature, knowing how it works from ahardware standpoint is critical to deploying it. As shown in FIG. 3, thesource measure switching system sequencer FPGA 130 provides a total of16 separate “windows” capable of accessing the entire 32 bit addressablecard memory space for all cards in the embodiment shown. Effectively thesequence engine 130 allocates a physical memory space of 2²⁸(268,435,456 bytes) to each card. The upper four bits of the total 32bit address space determine the desired slot number, 1-12, with slotnumbers 13-16 reserved for future use.

The up to 16 separate windows into card memory space allow the coreprocess at its discretion, to assign a unique window to an individualthread. Provided that no other thread inadvertently uses a window notassigned to it, atomicity between operations to the trio of registerswithin the window is not necessary. Consequently this allows thesoftware architecture to avoid overheads associated with mutex lockingnecessary to avoid race conditions in a shared arrangement.

The X Bus communication protocol has the ability to pipeline/burst datain block memory-mapped transfer mode for faster transfer times. Once aprogrammer specifies an address location in the memory select register,the FPGA 130 allows sequential accesses to either the card write or readregisters without another update. In fact, it is actuallycounter-productive to write to the address select register unlessnecessary since it forces a pipeline/burst reset of the X Buscommunication state machine.

As FIG. 4 highlights, each plug-in card installed in the source measureswitching system 100 preferably contains a flash memory device storing acomplete image of a Linux ext2 file system. When the Linux kernel startsand completes initial configuration and setup activities, it begins theprocess of loading installed kernel-level drivers. Obviously, toproperly access the X Bus 128, the software architecture for the sourcemeasure switching system 100 must provide a driver compiled with theLinux kernel that serves this function. Thus when the kernel first callsthe driver, it must do several things:

-   1) Inspect all slots to determine whether the slot contains a card    or is empty.-   2) Copy the file system image from detected, installed cards into    the main RAM memory of the CPU. The driver performs this activity    using the block memory-mapped transfer mode recently described.-   3) Mount the transferred images as Linux RAM disks to the root file    system, prefaced by a top directory indicating the slot from which    the image originated. At this point, the contents of each card's    flash memory appear as ordinary files.    Following this step, the Linux kernel starts the master init process    which then in turn starts all other child processes such as the web    server, the core source measure switching system firmware, and    miscellaneous Linux support processes as FIG. 5 illustrates. When    the core process begins execution it internally kicks off additional    activities that technically mark the third stage of system    initialization. Although the introduction briefly alluded to the    fact that the software architecture somehow marries different pieces    of firmware sourced by both the mainframe and installed cards, and    it didn't elaborate how to accomplish this, FIG. 6 highlights how    this is accomplished. With a file system mounted for each card    present in the system, the core process need only look into the    appropriate directory for the desired slot to locate the shared    library firmware specific to that card.

Normally, libraries pose some unique challenges to software architectureplanning. For starters, libraries under Linux fall into one of two majorclasses: static or dynamic. Static libraries are those with the “.a”suffix. This type of library must be re-linked to the main applicationanytime a change occurs within the library since the entry points forfunctions within the library are likely to move. The other challengethis library style creates occurs when multiple libraries with identicalfunction names are loaded. This creates ambiguous references for thelinker.

Clearly a static library arrangement is therefore not conducive to thesource measure switching system architecture. Not only does the embeddedenvironment lack native tool chains capable of re-linking theapplication to accommodate card libraries at startup, it is entirelypossible that identical plug-in cards with identical libraries (andfunction names) will exist in the system. The second major library classunder the Linux environment is dynamic in nature. This most common formtoday of this type of library is the shared dynamic library. A dynamicshared library typically carries a “.so” file suffix and can be found inthe root system library directory.

Unlike static libraries, dynamic shared libraries linked into anapplication do not get included with the application. Instead the linkermakes references to the function names used in an application for whichthe Linux kernel dynamically determines the execution entry points whenthe application first starts. While this technique provides asignificant improvement over static libraries, it still does not addresswhat happens if an application needs multiple libraries that use acommon API interface with identical function names.

Fortunately Linux provides a solution to this problem. Using the Linuxdlsym( ) function call, an application that requires support from aparticular library can determine a physical function pointer to thelibrary's implementation of a desired function. Hence this erasesambiguity since the running application controls this behavior ratherthan a context-unaware dynamic linker, as highlighted in FIG. 6. Thecore architecture builds tables of function pointers at system startupthat are referenced later in normal operation. The other key benefit tothis technique is that changes or updates to the libraries built outsideof the system do not present problems with legacy versions of the corefirmware—provided that the basic API does not change.

The core process is also responsible for launching subsidiary childprocesses that handle remote communications to the outside world.Effectively a dedicated remote communication handling process exists forany major communication pathway into the instrument. Consequently allGPIB communications use the GPIB remote communication process, dynamicweb-based accesses use the applet server remote communication process,and so forth.

The final stage of initialization for the source measure switchingsystem 100 from a software architecture standpoint is shown in FIG. 7.With connectivity to individual card-specific libraries complete, thecore firmware process now establishes sockets/pipes to remotecommunication servers, begins initialization activities required by userinterfaces such as the display, knob, and keypad, and performscard-specific initialization activities. Once these activities arecomplete, the system is fully functional and ready to accept controlinput from the outside world.

External SCPI Message Transport

As FIG. 2 shows, SCPI-based communication plays an important role in thesource measure switching system's user experience. This is a relativelyeasy-to-use and well-understood communication standard that many testand measurement companies adopted more than a decade ago for testinstrumentation and measurement products.

While the SCPI communication standard lost some favor during the VXIdays when hardware interfaces supported direct, high-speedregister-based access, it has regained value in ethernet-drivenproducts. Ethernet solutions (for which LXI embraces) are not conduciveto direct register-based access. Therefore a SCPI or other message-basedcommunication format must be adopted to facilitate communication. SinceSCPI offers hardware interface agnostic behavior that works equally wellwith ethernet, USB, and GPIB, this time-tested standard has an importantplace in the source measure switching system's software architecture.

The SCPI standard mandates certain behaviors that drive theimplementation of a single master SCPI message processor. Since thestandard requires sequential behavior in command execution andproscribes parallel command execution paths, this works to the advantageof a product like the source measure switching system with multipleremote interfaces capable of operating concurrently. From a codingstandpoint, implementing state machines based on sequential logic provesmuch simpler than those that have to account for parallel behavior. Eachremote interface therefore only need be served in a first-in, first-outround-robin arrangement.

With a presumption that a single master parser in the core sourcemeasure switching system's firmware process shall handle command andquery activity, other architecture-specific software details now comeinto focus. Described earlier and illustrated in FIG. 6, the corefirmware process has the responsibility of loading ancillary supportprocesses that act as remote communication servers to the outside world.While FIG. 6 serves a useful purpose in documenting the startup sequencefor the source measure switching system, it does not reveal how a remotecommunication server process should look internally or how it shouldinteract with the core firmware process. To fully appreciate the answerto this question, the software architecture must consider one additionaldetail.

Full compliance with the SCPI standard implies implementation of theIEEE-488.2 status reporting model. With the requirements establishedthus far, this software architecture implements a concept where one ormore independent “virtual” instrument clients operate an obscured,single “real” instrument. Each virtual instrument in effect isself-contained and implements complete message and error queues, aresponse buffer, and IEEE-488.2 status registers. For interfaces thatsupport multiple sessions like Ethernet, this approach easily allowseach session to act as a virtual instrument also.

One issue results from this approach however. The IEEE-488.2 statusreporting standard heralds from the days of GPIB—well before the idea ofa single instrument talking to multiple computers and users was evenpossible. Unfortunately this standard creates some problems when appliedto today's technology. The question about the significance of say the“PON” or power-on bit in the extended status register where multiple“virtual” instruments exist becomes grey—since this is technicallyrelated to the state of the real instrument and not the virtualinstrument. Clearly in the present approach every time a new virtualinstrument is opened the PON bit would be set which likely doesn'tadhere with the intentions of the standard.

The source measure switching system is fully compliant with IEEE-488.2status reporting model when the user sticks to using a single virtualclient. If the user decides to use more than one virtual client, it isunreasonable to assume the source measure switching system shouldreligiously comply with a standard that is impossible to satisfy becauseof future technical problems not foreseen when the standard firstevolved.

Unlike previous source measure switching systems, where the mainfirmware required a certain amount of card awareness in one form oranother, the present invention takes a different tack of distributedintelligence. It is possible using careful abstraction andcompartmentalization to create two separate pieces of firmware thatcommunicate with each other in a highly-generic sense without revealingor requiring any knowledge of how the other works internally.

If the abstraction and compartmentalization is divided cleanly betweenfirmware servicing the main source measure switching system instrumentand that provided by a particular card to service itself, thepossibility of introducing new cards with support for previouslyundefined features becomes a reality. This can all be done withoutrequiring main firmware updates, provided the role of the main firmwareis limited to overall message routing, system supervision, andcoordination activities between the outside world and individual cardspresent in the source measure switching system.

In practice, building the required level of abstraction andcompartmentalization is tricky. For starters, dynamically bringing twoor more completely different pieces of firmware together withoutrecompilation and relinking necessitates the use of a sophisticatedoperating system to carefully manage the interactions through pipes,sockets, file systems, and/or dynamic libraries.

Trigger Router

The test system's trigger router is a fully configurable trigger inputand trigger output routing matrix. The trigger router allows 16 triggerinputs. Twelve inputs are from twelve slots. Two inputs are from twoScan Sequencers, and two are from two external trigger inputs located onthe rear panel. Every trigger input can be configured via 4 detectionmodes: active high, active low, level high, and level low. Every triggerinput can be routed to every trigger output. Every trigger output can beconfigured for input to output delay, output edge active high or activelow, output level high or level low, trigger pulse width, trigger repeatcycles (auto or input triggered), and trigger scan interval timer.Trigger scan interval can be configured up to 1276 hours. Any triggeroutput can also be configured to be triggered on single trigger,multiple triggers, or auto trigger if set.

Trigger Control Registers

Trigger router control requires a group of registers for each triggerinput or output which are part of the trigger router. These are:

TROUTE(16-bit), TIN_ENB(1-bit), TOUT_ENB(1-bit), TIN_EDGE(1-bit),TIN_LEVEL(1-bit), TOUT_EDGE(1-bit), TOUT_LEVEL(1-bit),TRIGGER_ARM(1-bit), TRIGGER_AUTO(1-bit), TOUT_DELAY(16-bit),TOUT_WIDTH(16-bit), TOUT_DURA0(32-bit), TOUT_DURA1(4-bit), andTOUT_REPEAT(16-bit) registers. These registers are fully explained onTables 1.1 through 1.14. Trigger input and trigger output set up processis fully explained on Tables 1.15 through 1.18.

TABLE 1.1 TROUTE x Registers and Offset Address Register Name: TriggerInput to Output Route Register x (TROUTE x) CHIP CS6 SELECTS BaseAddress 0x000000 Offset See Table 1 Reset Value 0x00000000 AddressRegister Routes one or more trigger input to any trigger output. AccessR/W Description: ‘0’ - trigger input on the bit position is not routedto output. ‘1’ - trigger input set by the bit position is routed tooutput. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 01 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 N N N NN N N N N N N N N N N N T T S S C C C C C C C C C C C C / / / / / / / // / / / / / / / I I C C 1 1 1 9 8 7 6 5 4 3 2 1 A A A A A A A A A A A AA A A A N N A A 2 1 0 2 1 N N 2 1 Trigger Input to Output Delay Registerx (TROUTE x) Register Reset Bits Name Description Value Access 15:0Trigger Input Routes one or more trigger input to trigger 0 R/W Positionoutput x set by the bit position Registers Offset Address TTROUTE00x000000 TTROUTE1 0x000004 TTROUTE2 0x000008 TTROUTE3 0x00000C TTROUTE40x000010 TTROUTE5 0x000014 TTROUTE6 0x000018 TTROUTE7 0x00001C TTROUTE80x000020 TTROUTE9 0x000024 TTROUTE10 0x000028 TTROUTE11 0x00002CSCAN_ROUTE 1 0x000030 SCAN_ROUTE 2 0x000034 EXT_ROUTE1 0x000038

TABLE 1.2 TIN_ENB Registers and Offset Address Register Name: TIN_ENBCHIP CS6 SELECTS Base 0x000000 Offset 0x001000 Reset Value 0x00000000Address Address Register Enables trigger input for the routing matrix.Access R/W Description: ‘1’ - enable, ‘0’ - disable. 3 3 2 2 2 2 2 2 2 22 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 3 2 1 0 9 87 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 N N N N N N N N N N N N N N N N E ES S C C C C C C C C C C C C / / / / / / / / / / / / / / / / X X C C 1 11 9 8 7 6 5 4 3 2 1 A A A A A A A A A A A A A A A A T T A A 2 1 0 I I NN N N 2 1 2 1 TIN_ENB Register Reset Bits Name Description Value Access15:14 Tringger15_ENB:Trigger14_ENB Enables external trigger 0 R/W input2 and external trigger input 1 13:12 Trigger12_ENB:Trigger13_ENB Enablesscan sequencer 2 0 R/W and scan sequencer 1 input 11:0 Trigger11_ENB:Trigger0_ENB Enable trigger input 12 0 R/W down to 1

TABLE 1.3 TIN_EDG Registers and Offset Address Register Name: TIN_EDGCHIP CS6 SELECTS Base 0x000000 Offset 0x001004 Reset Value 0x00000000Address Address Register Sets input detection level/edge mode: Leveltrigger or Access R/W Description: Edge trigger. ‘0’ - Level trigger,‘1’ - Edge trigger 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 00 0 0 0 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 10 N N N N N N N N N N N N N N N N E E S S C C C C C C C C C C C C / / // / / / / / / / / / / / / X X C C 1 1 1 9 8 7 6 5 4 3 2 1 A A A A A A AA A A A A A A A A T T A A 2 1 0 I I N N N N 2 1 2 1 TIN_EDG RegisterReset Bits Name Description Value Access 15:14 TIN_EDG15:TTIN_EDG14 Setsdetection mode for 0 R/W external trigger input 2 and external triggerinput 1 13:12 TIN_EDG13:TIN_EDG12 Sets detection mode scan 0 R/Wsequencer 2 and scan sequencer 1 input 11:0  Trigger_EDG11:Trigger_EDG0Sets detection mode trigger 0 R/W input 12 down to 1

TABLE 1.4 TIN_LVL Registers and Offset Address Register Name: TIN_LVLCHIP CS6 SELECTS Base 0x000000 Offset 0x001008 Reset Value 0x00000000Address Address Register Sets input detection level after TIN_EDGregister is Access R/W Description: set: Level trigger mode: ‘0’ - level0, ‘1’ - level 1 Edge trigger mode: ‘0’ - falling edge, ‘1’ - risingedge 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 09 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 N N N N N NN N N N N N N N N N E E S S C C C C C C C C C C C C / / / / / / / / / // / / / / / X X C C 1 1 1 9 8 7 6 5 4 3 2 1 A A A A A A A A A A A A A AA A T T A A 2 1 0 I I N N N N 2 1 2 1 TIN_LVL Register Reset Bits NameDescription Value Access 15:14 TIN_LVL15:TIN_LVL14 Sets detection modefor external 0 R/W trigger input 2 and external trigger input 1 13:12TIN_LVL13:TIN_LVL12 Sets detection mode scan 0 R/W sequencer 2 and scansequencer 1 input 11:0  TIN_LVL11:TIN_LVL0 Sets detection mode triggerinput 0 R/W 12 down to 1

TABLE 1.5 TOUT_ENB Registers and Offset Address Register Name: TOUT_ENBCHIP CS6 SELECTS Base 0x000000 Offset 0x00100C Reset Value 0x00000000Address Address Register Enables trigger output Access R/W Description:‘1’ - enable, ‘0’ - disable. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 10 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 65 4 3 2 1 0 N N N N N N N N N N N N N N N N N E S S C C C C C C C C C CC C / / / / / / / / / / / / / / / / / X C C 1 1 1 9 8 7 6 5 4 3 2 1 A AA A A A A A A A A A A A A A A T A A 2 1 0 O N N U 2 1 T 1 TOUT_ENBRegister Reset Bits Name Description Value Access 14 TOUT_ENB14 Enablestrigger output to the 0 R/W external trigger output1 13:12TOUT_ENB13:TOUT_ENB12 Enables output to scan 0 R/W sequencer 2 and scansequencer 1 11:0  TOUT_ENB11:TOUT_ENB0 Enable trigger output 12 0 R/Wdown to 1

TABLE 1.6 TOUT_EDG Registers and Offset Address Register Name: TOUT_EDGCHIP CS6 SELECTS Base 0x000000 Offset 0x001010 Reset Value 0x00000000Address Address Register Sets output level/edge mode: Level trigger orEdge Access R/W Description: trigger ‘0’ - Level trigger, ‘1’ - Edgetrigger 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 01 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 N N N NN N N N N N N N N N N N N E S S C C C C C C C C C C C C / / / / / / / // / / / / / / / / X C C 1 1 1 9 8 7 6 5 4 3 2 1 A A A A A A A A A A A AA A A A A T A A 2 1 0 I N N N 2 1 1 TOUT_EDG Register Reset Bits NameDescription Value Access 14 TOUT_EDG14 Sets edge mode for external 0 R/Wtrigger output 1 13:12 TOUT_EDG13:TOUT_EDG12 Sets edge mode to output to0 R/W scan sequencer 2 and scan sequencer 1 input 11:0 TOUT_EDG11:TOUT_EDG0 Sets edge mode for trigger 0 R/W output 12 down to1

TABLE 1.7 TOUT_LVL Registers and Offset Address Register Name: TOUT_LVLCHIP CS6 SELECTS Base 0x000000 Offset 0x001014 Reset Value 0x00000000Address Address Register Sets output level after TOUT_EDG register isset: Access R/W Description: Level trigger mode: ‘0’ - Level 0, ‘1’ -level 1 Edge trigger mode: ‘0’ - falling edge, ‘1’ - rising edge 3 3 2 22 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 43 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 N N N N N N N N N N N NN N N N N E S S C C C C C C C C C C C C / / / / / / / / / / / / / / / // X C C 1 1 1 9 8 7 6 5 4 3 2 1 A A A A A A A A A A A A A A A A A T A A2 1 0 I N N N 2 1 1 TOUT_LVL Register Reset Bits Name Description ValueAccess 14 TOUT_LVL14 Sets level mode for external 0 R/W trigger input 113:12 TOUT_LVL13:TOUT_LVL12 Sets level mode for output to 0 R/W scansequencer 2 and scan sequencer 1 11:0  TOUT_LVL11:TOUT_LVL0 Setsdetection mode trigger 0 R/W output 12 down to 1

TABLE 1.8 TOUT_ARM Registers and Offset Address Register Name: TOUT_ARMCHIP CS6 SELECTS Base 0x000000 Offset 0x001018 Reset Value 0x00000000Address Address Register Trigger output state machine is ready after theAccess R/W Description: TOUT_ARM is set. Trigger output state machine ison standby after the TOUT_ARM is cleared. ‘1’ - arm, ‘0’ - disarm. 3 3 22 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 54 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 N N N N N N N N N N NN N N N N N E S S C C C C C C C C C C C C / / / / / / / / / / / / / / // / X C C 1 1 1 9 8 7 6 5 4 3 2 1 A A A A A A A A A A A A A A A A A T AA 2 1 0 I N N N 2 1 1 TOUT_ARM Register Reset Bits Name DescriptionValue Access 14 TOUT_ARM14 Arms external trigger output 1 0 R/W 13:12TOUT_ARM13:TOUT_ARM12 Arms output to scan 0 R/W sequencer 2 and scansequencer 1 11:0  TOUT_ARM11:TOUT_ARM0 Arms trigger output 12 0 R/W downto 1

TABLE 1.9 TOUT_AUTO Registers and Offset Address Register Name:TOUT_AUTO CHIP CS6 SELECTS Base 0x000000 Offset 0x00101C Reset Value0x00000000 Address Address Register Sets automatic trigger output AccessR/W Description: Trigger output state machine is on auto trigger withoutany trigger input source once the corresponding bit is set (1). Triggeroutput state machine is triggered on external input sources once thecorresponding bit is cleared (0). ‘1’ - set, ‘0’ - cleared. 3 3 2 2 2 22 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 3 21 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 E S S C C C C C C C C C C CC X C C 1 1 1 9 8 7 6 5 4 3 2 1 T A A 2 1 0 I N N N 2 1 1 TOUT_AUTORegister Reset Bits Name Description Value Access 14 TOUT_AUTO14 AUTOtrigger input 1 0 R/W 13:12 TOUT_AUTO13:TOUT_AUTO12 AUTO output to scan0 R/W sequencer 2 and scan sequencer 1 11:0  TOUT_AUTO11:TOUT_AUTO0 AUTOtrigger output 12 0 R/W down to 1

TABLE 1.10 TOUT_DELAY x Registers and Offset Address Register Name:Trigger Input to Output Delay Register x (TOUT_DELAYx) CHIP CS6 SELECTSBase 0x000000 Offset See Table 1 Reset Value 0x00000000 Address AddressRegister Provides trigger input to trigger output delay in 1 usec AccessR/W Description: increment for up to 4095 seconds. Min: 0 count => 0μsec; Max: 4294967296 => 4295 sec. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 11 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 98 7 6 5 4 3 2 1 0 D D D D D D D D D D D D D D D D D D D D D D D D D D DD D D D D 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 10 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 Trigger Input to OutputDelay Register x (TOUT_DELAYx) Register Reset Bits Name DescriptionValue Access 31:0 Delay Counter Min: 0 count => 0 μsec; Max: 4294967296=> 0 R/W 4295 sec. Registers Offset Address TOUT_DELAY0 0x002000TOUT_DELAY1 0x002004 TOUT_DELAY2 0x002008 TOUT_DELAY3 0x00200CTOUT_DELAY4 0x002010 TOUT_DELAY5 0x002014 TOUT_DELAY6 0x002018TOUT_DELAY7 0x00201C TOUT_DELAY8 0x002020 TOUT_DELAY9 0x002024TOUT_DELAY10 0x002028 TOUT_DELAY11 0x00202C TSCAN_DELAY 1 0x002030TSCAN_DELAY 2 0x002034 TEXTOUT_DELAY 1 0x002038

TABLE 1.11 TOUT_WIDTH x Registers and Offset Address Register Name:Trigger Output Pulse Width Register x (TOUT_WIDTH x) CHIP CS6 SELECTSBase 0x000000 Offset See Table 1 Reset Value 0x00000001 Address AddressRegister Controls the trigger pulse width for up to 65536 μsec. AccessR/W Description: Min: 1 => 1 μsec; Max 65536 => 65536 μsec. 3 3 2 2 2 22 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 3 21 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 N N N N N N N N N N N N N NN N D D D D D D D D D D D D D D D D / / / / / / / / / / / / / / / / 1 11 1 1 1 9 8 7 6 5 4 3 2 1 0 A A A A A A A A A A A A A A A A 5 4 3 2 1 0Trigger Output WIDTH Register x (TOUT_WIDTHx) Register Reset Bits NameDescription Value Access 31:0 Delay Counter Min: 1 => 1 μsec; Max 65536=> 65536 μsec. 0 R/W Registers Offset Address TOUT_WIDTH0 0x003000TOUT_WIDTH1 0x003004 TOUT_WIDTH2 0x003008 TOUT_WIDTH3 0x00300CTOUT_WIDTH4 0x003010 TOUT_WIDTH5 0x003014 TOUT_WIDTH6 0x003018TOUT_WIDTH7 0x00301C TOUT_WIDTH8 0x003020 TOUT_WIDTH9 0x003024TOUT_WIDTH10 0x003028 TOUT_WIDTH11 0x00302C TSCAN_WIDTH 1 0x003030TSCAN_WIDTH 2 0x003034 TEXTOUT_WIDTH 1 0x003038

TABLE 1.12 TOUT_DURA0 x Registers and Offset Address Register Name:Trigger Output Scan Interval Lower Long Word x (TOUT_DURA0 x) CHIP CS6SELECTS Base 0x000000 Offset See Table 1 Reset Value 0x0000000 AddressAddress Register In combination of TOUT_DURA1 x for controlling AccessR/W Description: total trigger duration. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 11 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 21 0 9 8 7 6 5 4 3 2 1 0 D D D D D D D D D D D D D D D D D D D D D D D DD D D D D D D D 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 43 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 Trigger Output ScanInterval Lower Long Word x (TOUT_DURA0 x) Register Reset Bits NameDescription Value Access 31:0 Duration 32-BIT Value. 0 R/W Counter LowerMin count: 0 => 0; Max count: 4294967296 32-bit counts. Registers OffsetAddress TOUT_DURA0_0 0x004000 TOUT_DURA0_1 0x004004 TOUT_DURA0_20x004008 TOUT_DURA0_3 0x00400C TOUT_DURA0_4 0x004010 TOUT_DURA0_50x004014 TOUT_DURA0_6 0x004018 TOUT_DURA0_7 0x00401C TOUT_DURA0_80x004020 TOUT_DURA0_9 0x004024 TOUT_DURA0_10 0x004028 TOUT_DURA0_110x00402C TSCAN_DURA0_1 0x004030 TSCAN_DURA0_2 0x004034 TEXTOUT_DURA0_10x004038

TABLE 1.13 TOUT_DURA1 x Registers and Offset Address Register Name:Trigger Output Scan Interval Upper Nibble x (TOUT_DURA1 x) CHIP CS6SELECTS Base 0x000000 Offset See Table 1 Reset Value 0x0000000 AddressAddress Register In combination of TOUT_DURA0 x for controlling AccessR/W Description: total trigger duration. 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 11 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 21 0 9 8 7 6 5 4 3 2 1 0 N N N N N N N N N N N N N N N N N N N N N N N NN N N N D D D D / / / / / / / / / / / / / / / / / / / / / / / / / / / /3 2 1 0 A A A A A A A A A A A A A A A A A A A A A A A A A A A A TriggerOutput Scan Interval Upper Nibble x (TOUT_DURA1 x) Register Reset BitsName Description Value Access 3:0 Duration 4-BIT Value: Min: 0; Max: 15.0 R/W Counter Higher 4-bit Registers Offset Address TOUT_DURA1_00x005000 TOUT_DURA1_1 0x005004 TOUT_DURA1_2 0x005008 TOUT_DURA1_30x00500C TOUT_DURA1_4 0x005010 TOUT_DURA1_5 0x005014 TOUT_DURA1_60x005018 TOUT_DURA1_7 0x00501C TOUT_DURA1_8 0x005020 TOUT_DURA1_90x005024 TOUT_DURA1_10 0x005028 TOUT_DURA1_11 0x00502C TSCAN_DURA1_10x005030 TSCAN_DURA1_2 0x005034 TEXTOUT_DURA1_1 0x005038 Notes:TOUT_DURA is equivalent to the scan interval and is formed by combiningTOUT_DURA1 & TOUT_DURA0 => 36-bit. Max count: 68719476736 => 191.88hours with step-size of 10 μsec.

TABLE 1.14 TREPEAT0_x Registers and Offset Address Register Name:Trigger Output Repeat Counter Register x (TREPEAT_x) CHIP CS6 SELECTSBase 0x000000 Offset See Table 1 Reset Value 0x0000000 Address AddressRegister Sets the trigger output to detect trigger input or auto AccessR/W Description: output for repetition cycles set by this registers.16-bit counter 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 00 0 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 NN N N N N N N N N N N N N N N D D D D D D D D D D D D D D D D / / / / // / / / / / / / / / / 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0 A A A A A A A A AA A A A A A A 5 4 3 2 1 0 Trigger Output Repeat Count Register x(REPEAT_x) Register Reset Bits Name Description Value Access 15:0 RepeatCounter 16-bit. Min: 1 count; Max 65536 counts; 1 R/W 16-bit RegistersOffset Address TREPEAT0_0 0x006000 TREPEAT0_1 0x006004 TREPEAT0_20x006008 TREPEAT0_3 0x00600C TREPEAT0_4 0x006010 TREPEAT0_5 0x006014TREPEAT0_6 0x006018 TREPEAT0_7 0x00601C TREPEAT0_8 0x006020 TREPEAT0_90x006024 TREPEAT0_10 0x006028 TREPEAT0_11 0x00602C TSCAN_REPEAT_10x006030 TSCAN_REPEAT_2 0x006034 TEXTREPEAT_1 0x006038Trigger Input and Output Configuration Process

FIG. 8 shows the flow of the trigger input configuration process. Thesettings of the trigger input and output are sequenced in the followingmanner:

TABLE 1.15 Trigger Input Configuration Process Registers Write NotesTIN_ENB Enables Trigger input x TIN_EDG Sets edge or level for triggerinput TIN_LVL Sets input to ‘0’ or ‘1’ for level trigger, falling orrising edge for edge trigger.

Then the trigger output can be configured individually as illustrated bythe flow diagram in FIG. 9

TABLE 1.16 Trigger Output Configuration Process Registers Write NotesTOUT_ENB Enables configuration for trigger output TOUT_EDG Sets Edge orlevel mode for output TOUT_LVL Sets output to level ‘0’ or ‘1’ withlevel mode, Falling or rising edge with edge mode. TROUTE_x Routes anyone or more trigger input to trigger output x TOUT_DELAY_x Sets triggerinput to trigger output delay for trigger output #x TOUT_WIDTH x Setsoutput pulse width to trigger output #x TOUT_DURA0 x Sets lower longword of scan interval register for trigger output #x (trigger input tooutput lock out) TOUT_DURA1 x Sets higher 4-bit of scan interval fortrigger output #x TREPEAT x Sets trigger output #x repeat countTOUT_AUTO Sets trigger output #x to auto TOUT_ARM Arms trigger output #xTrigger Input and Output by Examples

Trigger configurations can be best illustrated by examples As shown inFIGS. 10 and 11, trigger input #1 is detected on the falling edge,trigger input #3 is detected on the rising edge, and trigger input #8 isdetected on level ‘1’ (level high). Trigger output to card #5 is set tobe triggered on trigger input #3 twice. The trigger output is configuredto as falling edge. The trigger input to output delay is set to 43981μsec. The trigger pulse width is 2099 μsec. The trigger duration timeris set at 0.40960 sec. Auto mode is off.

Trigger output to card #7 is set to auto-triggered and be repeated 5times. The trigger output is configured to as rising edge. The triggeroutput delay is at 15.663 sec. The trigger pulse width is 2357 μsec. Thetrigger scan interval timer is set at 0.45056 sec.

Trigger output to card #8 is set to be triggered on trigger input #1three times. The trigger output is configured to as rising edge. Thetrigger input to output delay is set to 15.663 sec. The trigger pulsewidth is 2099 μsec. The trigger scan interval timer is set at 0.53248sec. Auto mode is off.

Trigger output to scan #1 is set to be triggered on trigger input #8 onsingle shot. The trigger output is configured to as rising edge. Thetrigger input to output delay is set to 0 sec. The trigger pulse widthis 1792 μsec. The trigger scan interval timer is set at 0. Auto mode isoff.

TABLE 1.17 Trigger Input Configuration Process by Examples RegistersWrite Example Notes TIN_ENB 0x00000085 Enables Trigger input 1, 3, and 8for configurations TIN_EDG 0x00000085 Input 1, 3 edge, Input 8 levelTIN_LVL 0x00000084 Input 1 falling edge Input 3 rising edge Input 8level high

Then the trigger output can be configured individually.

TABLE 1.18 Trigger Output Configuration Process by Examples RegistersWrite Example Notes TOUT_ENB 0x00002070 Enables output to #5, 7, 8, andscan 1 for configuration TOUT_EDG 0x000010D0 Output 5, 7, 8, Scan 1 EdgeTOUT_LVL 0x00003040 Output 5 level ‘0’ Output 7 rising edge Output 8falling edge Scan 1 rising edge TROUTE_4 0x00000002 Trigger input #3routed to trigger output #5 TROUTE_6 0x00000000 Trigger input #7 set toauto trigger TROUTE_7 0x00000001 Trigger input #1 routed to triggeroutput #8 TROUTE_13 0x00000080 Trigger input #8 routed to scan #1TOUT_DELAY_4 0x0000ABCD Sets output # 5 delay (43981 μsec) TOUT_DELAY_60x000000EF Sets output #7 delay (236 μsec) TOUT_DELAY_7 0x00EF0000 Setsoutput #8 delay (0 sec) TOUT_DELAY_13 0x00000000 Sets output scan 1delay (15.663 sec) TOUT_WIDTH4 0x00000833 Sets output #5 width (2099μsec) TOUT_WIDTH6 0x00000833 Sets output #7 width (2099 μsec)TOUT_WIDTH7 0x00000935 Sets output #8 width (2357 μsec) TOUT_WIDTH130x00000700 Sets output scan1 width (1792 μsec) TOUT_DURA0_4 0x0000A000Sets Trigger scan interval #5 (0.40960 sec) TOUT_DURA0_6 0x0000D000 SetsTrigger scan interval #7 (0.53248 sec) TOUT_DURA0_7 0x0000B000 SetsTrigger scan interval #8 (0.45056 sec) TOUT_DURA0_13 0x00000000 SetsTrigger scan interval #13 (0 sec) TOUT_DURA1_4 0x00000000 TOUT_DURA1_60x00000000 TOUT_DURA1_7 0x00000000 TOUT_DURA1_13 0x00000000 TREPEAT_40x00000002 Sets output #5 repeat count (2 times) TREPEAT_6 0x00000005Sets output #7 repeat count (5 times) TREPEAT_7 0x00000003 Sets output#8 repeat count (3 times) TREPEAT_13 0x00000001 Sets output to scan 1single shot TOUT_AUTO 0x00000040 Sets output #7 to auto trigger TOUT_ARM0x00002070 Readies trigger input for trigger output to #5, 7, 8, andscan 1.

FIG. 12 shows a detailed block diagram of a test system in accordancewith an embodiment of the invention, while FIG. 13 highlights a blockdiagram of the backplane board for test system 100. In FIG. 14 a diagramof a trigger circuit for use in test system 100 is shown and FIG. 15shows a trigger router in accordance with an embodiment of theinvention.

The trigger router shown in FIG. 15 shown in FIG. 15 includes aplurality of trigger input ports and a plurality of trigger outputports. The plurality of trigger input ports are coupled to the X-bus andthe PXI-bus sources as well as external triggers and a trigger from aSCAN. Coupled to the plurality of trigger input ports is a programmableinput sensitivity control circuit used for independently programming thetrigger sensitivity for each of the plurality of input triggers forpositive-edge sensitivity, negative-edge sensitivity, high statesensitivity or low state sensitivity. Coupled to the plurality of outputports is a programmable output sensitivity control circuit forindependently programming the trigger sensitivity of each of theplurality of output triggers for positive-edge sensitivity,negative-edge sensitivity, high state sensitivity or low statesensitivity. The trigger router shown in FIG. 15 is preferably locatedwithin the sequencer (sequence engine) which in an embodiment comprisesa Field Programmable Gate Array (FPGA).

As shown in FIG. 15, a delay circuit can be used to delay signalsflowing from the trigger router matrix to the plurality of output ports.Show on the left hand side of FIG. 15 is a group of trigger inputcontrol registers coupled to the input side of the trigger router matrixand a group of trigger output control registers coupled to the outputportion of the trigger router matrix. These input and output controlregisters have been previously described above. Also shown are multipleexternal trigger inputs, an auto trigger input on the input side as wellas an external trigger output and a trigger to scan line on the outputside. The trigger matrices on the input and output sides can be designedusing relays or other well known switching elements in order to allowany one or more of the inputs to interconnect with one or more of theoutputs.

While the preferred embodiments of the invention have been illustratedand described, it will be clear that the invention is not so limited.Numerous modifications, changes, variations, substitutions andequivalents will occur to those skilled in the art without departingfrom the spirit and scope of the present invention as defined by theappended claims.

1. A trigger router, comprising: a plurality of input ports forreceiving a plurality of input triggers; a plurality of output ports foroutputting a plurality of output triggers; a programmable inputsensitivity control circuit coupled to the plurality of input ports forindependently programming the trigger sensitivity for each of theplurality of input triggers for positive-edge sensitivity, negative-edgesensitivity, high state sensitivity or low state sensitivity; aprogrammable output sensitivity control circuit coupled to the pluralityof output ports for independently programming the trigger sensitivity ofeach of the plurality of output triggers for positive-edge sensitivity,negative-edge sensitivity, high state sensitivity or low statesensitivity; a trigger matrix; a group of trigger input controlregisters coupled to the plurality of input triggers; and a group oftrigger output control registers coupled to the plurality of outputtriggers, the group of trigger input control registers and the group oftrigger output registers control the trigger matrix for interconnectingthe plurality of input triggers with the plurality of output triggers.2. A trigger router as defined in claim 1, wherein the plurality ofinput triggers are generated by a first bus and a second bus and atleast one external trigger source.
 3. A trigger router as defined inclaim 1, wherein a trigger signal from a trigger source selected fromamong an internal trigger, a bus trigger, an external trigger, a timerand a user-defined trigger source causes the trigger router to activate.4. A trigger router as defined in claim 3, wherein a trigger sourcecommand determines which trigger source is selected for the execution ofimmediate commands.
 5. A trigger router as defined in claim 1, whereinthe trigger router is located within a real time sequencer.
 6. A triggerrouter as defined in claim 5, wherein the real-time sequencer is coupledto a first bus and a controller.
 7. A trigger router as defined in claim6, wherein the real-time sequencer comprises a field programmable gatearray (FPGA).